00U004 


IBM    DATA  BASE/DATA 
COMMUNICATION  STRATEGIES 
FOR    THE    I  980s 


Prepared  For: 
AGENCE  DE  L'INFORMATIQUE 


AUGUST  1981 


Digitized  by  the  Internet  Archive 

in  2015 


https://archive.org/details/ibmdatabasedatac11unse 

r 


IBM  DATA  BASE/DATA  COMMUNICATION  STRATEGIES 

FOR  THE  1980s 


CONTENTS 


Page 

I  BACKGROUND  AND  ISSUES   I 

A.  Background  I 

1.  Data  Models  And  Standards  I 

2.  Initial  IBM  DBMS  System  2 

B.  Issues  3 

II  SIGNIFICANCE  OF  IBM's  DB/DC  STRATEGY   5 

A.  Current  Status  5 

B.  What  IBM  Wants  To  Do  9 

III  TECHNICAL  AND  COMPETITIVE  IMPACTS  ON  IBM's 

STRATEGY   15 

A.  The  Threat  From  The  Bottom  15 

B.  Data  Base  Machines  17 

C.  The  Threat  From  Within  20 

D.  The  Threat  From  Without  20 

IV  PREDICTING  WHAT  IBM  WILL  DO   25 

A.  Evolution  Or  Revolution  25 

B.  The  Architecture  Of  Future  DB/DC  Networks  26 

C.  Projected  Announcement  Dates  For  New  Technology  30 


i 


INPUT 

Y-INF-ll 


IBM  DATA  BASE/DATA  COMMUNICATION  STRATEGIES 

FOR  THE  1980s 

EXHIBITS 

Page 

II      -I      A  Future  Distributed  Processing  Model  I  I 

27 
31 


IV      -I      Potential  Network  Architecture 
-2      IBM's  Preferred  DBMS  Timing 


-  ii  - 


INPUT 


I    BACKGROUND    AND  ISSUES 


I         BACKGROUND  AND  ISSUES 


A.  BACKGROUND 

I.        DATA  MODELS  AND  STANDARDS 

•  As  soon  as  data  base  management  systems  (DBMS)  started  to  emerge  as  a 
popular  concept,  several  things  occurred: 

CODASYL  formed  a  Data  Base  Task  Group  (DBTG)  both  to  determine 
what  this  strange  beast  was  and  to  prevent  some  of  the  standards 
conflicts  that  always  arise  in  implementation. 

Both  GUIDE  and  SHARE  formed  their  own  DBTG. 

The  conflict  began  over  whether  standards  should  be  developed  and,  if 
so,  what  they  should  be. 

•  Much  of  this  controversy  revolves  around  data  models,  of  which  three  are  of 
major  importance:  hierarchical,  network,  and  relational.  They  are  important 
for  understanding  what  IBM  has  done  concerning  DBMS,  and  what  it  may  do  in 
the  future. 
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The  hierarchical  model  is  actually  a  special  case  of  the  network  model. 
It  has  the  advantage  of  facilitating  implementation  of  applications  from 
a  programmer's  point  of  view. 

The  network  model  was  developed  with  the  more  sophisticated  user  in 
mind  -  one  who  understands  the  importance  of  the  data  base  adminis- 
trator. It  has  the  advantage  of  providing  many  tools  to  permit  the 
optimization  of  the  data  base  structure  and  operation.  The  result  is  a 
more  efficient  system. 

The  relational  model  was  developed  with  the  end  user  in  mind.  The 
result  is  an  easy-to-use  ("friendly")  system. 

There  has  also  been  considerable  speculation  about  a  coexistence  model 
that  would  accommodate  the  best  of  all  three  of  the  above. 

Essentially,  early  standards  efforts  focused  on  the  network  model  because  IDS 
used  that  model.  However,  IBM  decided  to  concentrate  on  the  hierarchical 
model  with  IMS.  The  relational  model  was  left  up  to  the  academic  types  (both 
internal  and  external  to  IBM). 

To  this  day,  there  is  controversy  not  only  about  which  model  is  best  and  which 
should  be  a  standard,  but  about  the  technical  aspects  of  the  models  them- 
selves. This  technical  competition  among  vendors  and  within  standards 
organizations  is  not  new  -  one  has  only  to  think  about  COBOL,  ASCII,  and 
SDLC.  However,  the  potential  for  creating  systems  monstrosities  has  never 
been  so  great  as  with  DBMS. 

INITIAL  IBM  DBMS  SYSTEM 

There  were  many  internal  IBM  DBMS  systems  that  never  became  available  to 
IBM  customers  as  products.  The  three  components  that  did  become  available 
all  started  as  independent  efforts  without  plans  for  eventual  integration, 
specif icially,  IMS,  CICS,  and  GIS. 


These  major  IBM  systems  have  been  around  for  over  ten  years  and  have  been 
integrated  using  a  variety  of  interfaces,  tools,  and  add-ons  that  were  never 
contemplated  when  the  systems  were  designed. 

GIS  can  trace  genealogy  back  through  the  formatted  file  system  to 
early  government  command  and  control  systems. 

IMS,  on  the  other  hand,  is  a  relative  "Johnny-come-lately"  -  having  been 
started  in  North  American  Aviation  Space  Division  as  part  of  the  Apollo 
moon-landing  program. 

Individual  IBM  customers  have  spent  millions  of  dollars  converting  to  IMS,  and 
others  have  plans  to  do  so.  Unfortunately,  there  has  been  dissatisfaction  with 
the  results  achieved  by  many  users,  as  well  as  continuing  rumors  concerning  a 
new  relational  system  (System  R).  However,  years  have  slipped  past  withoyj 
any  significant  announcement  from  IBM  in  the  data  base  area  (except  for 
System/38  which  is  aimed  at  end  users). 
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The  purpose  of  this  report  is  to  assess: 

What  IBM  would  like  to  do  in  the  data  base/data  communication 
(DB/DC)  area. 

The  pressures  that  may  impact  IBM's  plan. 

The  impact  of  IBM's  strategy  on  the  marketplace. 
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I  I    SIGNIFICANCE   OF   IBM'S   DB/DC  STRATEGY 
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II        SIGNIFICANCE  OF  IBM'S  DB/DC  STRATEGY 


A.       CURRENT  STATUS 


•  The  concept  of  host  computers  driving  large  centralized  data  bases  has  been  at 
the  heart  of  IBM'S  DB/DC  strategy.  Regardless  of  the  DBMS  employed,  large 
data  bases  require  large  centralized  computer  systems  for  both  processing 
power  and  storage  requirements.  IBM's  Systems  Network  Architecture  (SNA) 
supports  this  strategy,  and  it  has  been  quite  successful  in  the  past.  However, 
there  are  indications  of  trouble. 

IMS  has  been  so  successful  in  burning  CPU  cycles  that  even  the  recently 
announced  IBM  3081  Processor  Complex  will  have  difficulty  providing 
satisfactory  performance  levels  in  many  environments. 

Some  of  the  data  bases  being  developed  are  literally  becoming  unman- 
ageable (for  example,  data  bases  that  cannot  be  reorganized  on  any 
reasonable  timeframe). 

There  is  increasing  apprehension  on  the  part  of  many  companies  to  put 
all  these  eggs  in  one  basket  for  reasons  of  security. 

Many  companies  that  went  to  considerable  expense  to  centralize  are 
now  beginning  to  decentralize  because  of  end  user  dissatisfaction  with 
their  central  service  organizations. 
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Cheap,  responsive  alternatives  are  becoming  increasingly  available 
from  vendors  -  both  hardware  and  computer  services  -  which  are 
marketing  directly  to  end  users. 

While  aware  of  these  tendencies  among  its  client  base,  IBM  is  caught  in  a 
rather  difficult  situation  with  regard  to  its  DB/DC  strategy  for  the  following 
reasons: 

IMS  has  been  successful  in  selling  hardware. 

Corporate  management  in  IBM  does  not  want  to  become  committed  to 
development  and  maintenance  of  a  totally  new  DB/DC  system  because 
of  past  difficulties  and  expense  associated  with  such  systems. 

IMS  will  not  go  away  even  if  such  a  commitment  were  made.  Too  many 
IBM  customers  have  invested  too  much  money  in  IMS. 

Conventional  attempts  to  "bridge"  between  IMS  and  relational  systems 
(such  as  the  much  rumored  System  R)  have  demonstrated  performance 
characteristics  that  are  unacceptable  even  to  those  accustomed  to  IMS. 

Therefore,  IBM  has  developed  larger  and  larger  processors  in  an  effort  to  solve 
the  DB/DC  problem.  This  has  the  advantage  of  being  a  classic  strategy  with 
which  IBM  feels  quite  comfortable,  and  the  game  will  be  played  as  conserva- 
tively as  possible. 

The  announcement  of  the  IBM  3081  is  a  good  example  of  this  conservative 
approach. 

The  announcement  contained  no  significant  relief  for  DB/DC  users 
other  than  raw  processing  power  at  the  host. 

The  potential  for  architectural  distribution  of  data  base  functions  was 
not  promised  or  addressed  in  the  technical  documentation. 


The  long-anticipated  relational  DBMS  was  not  in  evidence. 

However,  a  few  weeks  before  the  H-Series  announcement  there  were  several 
news  items  of  importance  for  future  developments. 

An  IBM  employee  was  quoted  as  saying  a  bridge  between  IMS  and  a 
relational  system  was  "impossible." 

One  week  later,  IBM  officially  denied  the  quotation,  stating  that  while 
"...the  problem  of  supporting  both  hierarchic  applications  and  relational 
applications  on  shared  data  is  hard... it  is  still  being  worked  on." 

Software  AG  announced  a  data  base  machine  (DBM)  that  can  off-load 
IBM  mainframes  using  Adabas  (an  inverted  file  DBMS  having  "relational 
characteristics"). 

Later,  IBM  announced  a  new  release  of  IMS  that  allows  multiple  sharing 
of  data  bases  and  communications  sharing  with  other  VTAM-based 
systems.  This  could  be  the  first  step  toward  building  the  bridge  to  a 
relational  DBMS. 

INPUT  concludes  from  these  events  that: 

IBM  probably  has  a  workable  bridge  between  hierarchical  and  relational 
data  models  for  most  applications.  In  fact,  it  may  be  a  complete  bridge 
that  IBM  just  does  not  want  to  announce. 

If  Software  AG  has  been  able  to  develop  a  backend  DBM,  IBM  most 
certainly  has  the  capability  of  doing  so. 

While  this  report  was  being  prepared  a  "breakthrough"  in  DBMS  performance 
was  announced  by  Comshare  Inc. 
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The  system  that  will  be  called  Commander  4  is  based  on  extended  set 
theory.  Comshare  has  reportedly  developed  two  prototype  systems  to 
test  feasibility. 

They  are  satisfied  that  set  theoretic  systems  will  "...not  only  boost 
performance  to  unprecedented  levels,  but  can  be  used  with  virtually  any 
data  model  including  a  Codasyl  product." 

The  only  other  company  working  on  theoretic  architecture  is  Set 
Theoretic  Information  Systems  Corporation  (STIS). 

Evidently  the  idea  has  been  around  for  over  10  years,  but  has  had 
practically  no  impact.  The  system  would  be  implemented  on  a  "highly 
intelligent  backend"  (HIBE)  that  would  cost  $1.2  million  to  build. 

One  of  the  problems  with  theoretic  products  is  that  the  underlying 
theory  is  difficult  to  understand.  Eor  example,  Ted  Codd,  who  has 
pioneered  IBM's  work  in  relational  systems,  has  reportedly  remarked 
that  the  published  papers  are  "obscure." 

Comshare  finally  sent  one  of  its  senior  research  staff  members  to  study 
the  underlying  theory  for  a  year  and  a  half.  The  company  is  now 
convinced  that  David  A.  Childs  (STIS's  president)  really  has  the  answer 
to  DBMS  performance  problems. 

The  performance  of  the  working  prototypes  is  reported  to  be  "four 
times  as  fast  as  relational." 

•  INPUT  does  not  anticipate  that  IBM  will  announce  such  a  system  in  the 
foreseeable  future,  since  it  has  put  so  much  work  into  relational  systems. 
However,  it  is  probable  that  new  theories  and  architectures  will  eventually 
replace  current  thinking  and  implementation.  Certainly  there  is  plenty  of 
room  for  improvement  in  current  IBM  systems,  and  somewhere  within  IBM 
someone  other  than  Codd  is  unguestionably  studying  theoretic  systems. 
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B. 


WHAT  IBM  WANTS  TO  DO 


•  The  main  thing  IBM  wants  to  do  is  control  the  impact  of  any  new  system 
hardware  or  software  -  on  revenue.  Once  this  is  understood,  it  becomes  easier 
to  project  what  it  wants  to  do  in  the  DB/DC  area. 

•  IBM  has  been  successful  in  selling  IMS  despite  severe  performance  problems. 
As  customers  continue  with  plans  to  convert  applications  to  IMS,  there  is 
significant  potential  for  additional  hardware  sales  of  large-scale  mainframes 
and  storage.  Lower  costs  for  central  processors  will  entice  more  and  more 
customers  in  this  direction  -  even  those  climbing  the  4300  series  ladder. 

•  The  longer  a  new  DBMS  announcement  can  be  delayed,  the  more  customers 
will  be  confronted  with  hybrid  systems  once  something  new  is  announced. 
Regardless  of  the  way  the  bridge  is  constructed,  it  will  be  costly.  The 
preferred  strategy  would  be  as  follows: 

Announce  (or  deliver)  a  new  DBMS  only  after  maximum  hardware 
purchases  have  been  made  of  current  mainframes,  and  IMS  is  being  used 
by  most  potential  customers. 

Once  announced  (with  a  bridge),  encourage  using  the  new  DBMS  for  new 
applications.  It  will  be  easy  to  use,  but  performance  will  probably 
suffer,  especially  in  an  environment  where  IMS  applications  are  sharing 
the  same  data. 

The  performance  characteristics  could  be  even  worse  if  it  is  decided  to 
support  network  data  models  under  the  same  umbrella. 

•  As  long  as  the  hybrid  systems  can  be  supported  by  larger  mainframes,  IBM 
would  prefer  to  ignore  off-loading  the  large  hosts  with  either  backend  DBMs, 
or  through  distributed  data  base  support  (both  of  which  have  a  lot  in  common). 
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However,  relational  DBMSs  have  great  potential  for  distributed  processing 
because  of  their  "user-friendly"  interface.  It  is  probable  that  IBM  will 
encourage  the  use  of  such  systems  at  distributed  nodes  within  the  network. 
This  has  several  advantages: 

It  will  be  easier  for  users  to  develop  new  applications  -  a  real  plus. 


The  nodes  will  continue  to  depend  on  data  from  the  host,  but  will  also 
be  subject  to  growth,  which  will  practically  force  them  to  IBM's  main 
product  line  (rather  than  to  minicomputers  or  GSD  products  such  as 
system  38,  which  has  relational  capability). 

In  other  words,  anticipate  distributed  nodes  that  will  look  like  those  in 
Exhibit  ll-l. 

As  mentioned  previously,  IBM  will  be  conservative  in  its  approach  to  DB/DC. 
It  is  probable  that  both  backend  and  distributed  DBMs  are  not  scheduled  to 
appear  until  the  mid-1980s.  INPUT  continues  to  feel  that  there  will  be 
pressure  from  externa!  sources,  which  may  force  an  earlier  announcement. 
The  Software  AG  announcement  is  only  one  example. 


However,  IBM  would  like  to  do  the  following: 


Delay  the  announcement  of  a  relational  DBMS  until  after  3081s  start  to 
be  delivered  in  fourth  quarter  1981. 

Make  it  available  on  4300s  and  308Xs  only.  This  would  effectively  kill 
the  3033,  which  is  the  last  survivor  of  the  303X  series. 

Ignore  any  problems  of  compatibility  with  GSD  system,  including 
System  38. 

Proceed  slowly  toward  distributed  data  base  systems  using  4300s,  or 
smaller  versions  of  308Xs  at  the  nodes. 
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EXHIBIT  11-1 


A  FUTURE  DISTRIBUTED  PROCESSING  MODEL 
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Begin  to  encourage  the  maintenance  of  backup  data  bases  at  central 
hosts  for  security  purposes.  This  will  be  based  upon  the  availability  of 
"cheap"  communications  to  the  host  and  will  be  something  of  a 
departure  from  IBM's  traditional  opposition  to  duplicate  data  bases. 

By  1984-1985,  IBM  should  be  in  a  position  to  start  growing  the  nodes 
into  ever  larger  installations  as  data  procesing  and  office  automation 
begin  to  become  integrated.  Host  systems  would  serve  primarily  as 
control  centers  providing: 

Central  dictionaries  and  directories. 

Backup  facilities  for  operating  data  bases. 

High-security  depositories  for  sensitive  corporate  and  personal 
information. 

Responsibility  for  continuing  responsiveness  to  multiple  (and 
incompatible)  data  base  systems  that  will  exist  both  within  and 
outside  of  the  enterprise. 

Primary  control  point  for  internal  networks  and  for  inter- 
connection with  all  external  networks  in  order  to  monitor  data 
and  information  flow. 

•         This  scenario  represents  the  best  of  all  posssible  worlds  from  IBM's  point  of 
view. 

Data  bases  at  central  hosts  will  continue  to  grow,  requiring  ever  larger 
processors  and  storage  devices. 
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This  will  result  from  providing  services  to  smaller  sysems  at  the 
network  nodes,  which  are  also  positioned  to  grow  to  large  systems  in 
response  to  the  enormous  data  and  information  requirements  as  offices 
become  automated. 

The  advantages  to  IBM  of  such  a  strategy  are  clear.  There  will  be  double, 
triple,  and  even  quadruple  duplication  of  data,  information,  hardware,  and 
software.  In  addition,  the  DB/DC  systems  to  support  such  a  distributed  data 
base  would  defy  duplication  by  any  competitor. 

The  danger  to  IBM  is  that  the  very  complexity  of  the  DB/DC  system  will  cause 
it  to  eventually  fall  of  its  own  weight  before  it  can  be  effectively  imple- 
mented. This  would  come  about  primarily  because  neither  the  data  base 
systems,  nor  the  communications  systems,  nor  the  operating  systems  were 
designed  to  function  efficiently  in  such  an  environment.  Also,  progress  is 
being  made  by  competitors  who  have  had  an  opportunity  to  start  with  better 
architectures.  This  could  force  drastic  changes  in  IBM's  strategy,  resulting  in 
speed-up,  at  least,  of  the  announcement  schedules. 

In  other  words,  it  is  doubtful  that  IBM  will  develop  a  true  coexistence  model. 
The  plan  will  be  to  develop  complex  bridge  systems  to  integrate  existing 
DBMSs. 
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TECHNICAL  AND  COMPETITIVE  IMPACTS  ON  IBM'S  STRATEGY 


THE  THREAT  FROM  THE  BOTTOM 

•  IBM's  DB/DC  strategy  is  the  product  of  the  Data  Processing  Division  (DPD), 
which  is  accustomed  to  dealing  with  data  processing  people,  not  end  users. 
The  success  of  the  strategy  depends  upon  slowly  pushing  computer  and  access 
to  information  to  end  users.  The  ability  of  designers,  accustomed  to 
supporting  large  systems  used  by  programmers,  to  successfully  implement 
"user-friendly"  systems  has  to  be  suspect. 

The  primary  design  point  of  the  great  grandfather  of  MVS  (OS/360)  was 
ease  of  use.  The  result  was  a  system  so  complex  that  JCL  is  even 
worse  to  deal  with  than  most  programming  languages. 

Query-By-Example  (QBE),  a  nonprocedural  language  for  use  with  rela- 
tional systems,  was  developed  by  IBM's  research  facility  in  Yorktown 
Heights,  where  most  of  the  employees  have  never  been  exposed  to 
commercial  applications. 

SQL  (Sequel)  was  developed  for  use  with  System  R  in  what  amounted  to 
an  academic  environment  in  San  Jose. 


ill 
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Both  of  the  above  languages  have  been  tested  primarily  with  systems 
people  and  not  with  regular  office  workers. 

In  addition,  there  is  always  a  tendency  among  sysems  designers  to  keep 
adding  functions  (and  accompanying  complexity). 

It  is  probable  that  designers  of  minicomputers,  small  business  systems,  and 
word  processing  systems  will  design  systems  that  appear  more  friendly  to  end 
users.  (This  includes  IBM's  GSD  and  OPD,  along  with  the  outside  competitors.) 

In  addition,  the  probability  of  dedicated  systems  for  local  data  bases  will 
create  not  only  performance  imbalance  (extreme  slowing  of  transactions 
requiring  host  processing),  but  will  expose  the  inefficiencies  associated  with 
centralized  data  bases.  The  tendency  will  be  to  distribute  data  bases  to  end 
users  rapidly  rather  than  on  an  IBM-controlled  basis.  Generally  speaking, 
these  local  data  bases  will  represent  the  operational  data  of  the  local 
establishment. 

A  logical  extension  of  local  data  bases  with  fast  response  time  is  the  personal 
data  base,  where  an  individual  has  complete  control  over  the  entire  data  base. 

The  individual  may  be  an  engineer,  professional  person,  or  executive. 
However,  the  thing  which  characterizes  these  persons  is  that  most  of 
the  processing  power  and  storage  needed  can  be  encompassed  within  a 
personal  computer. 

It  is  INPUT'S  opinion  that  a  high  percentage  of  white  collar  workers 
could  benefit  from  the  use  of  a  "friendly"  personal  computer  -  whether 
for  entry  or  retrieval  of  messages  or  reports,  or  for  problem  solving 
(computation).  A  personal  computer  represents  only  a  modest  invest- 
ment when  considering  today's  personnel  costs.  The  effect  of  all  this  is 
the  off-loading  of  the  large  central  mainframe  in  favor  of  a  more 
responsive  personal  system. 


-  16- 


INPU" 


B.       DATA  BASE  MACHINES 


•  The  concept  of  building  ever  larger,  general-purpose  processors  must  even- 
tually end.  Processors  are  becoming  so  cheap  that  they  can  be  dedicated  to  an 
individual  (such  as  the  personal  computers  mentioned  previously)  or  to  specific 
computing  functions.  This  has  given  rise  to  the  concept  of  DBMs. 

•  Conceptually,  DBMs  fall  into  at  least  three  categories: 

Backend  systems  for  off-loading  large  central  hosts. 

At  nodes  in  a  network  for  general-purpose  computing,  as  a  standalone, 
or  connected  into  the  network. 

Smart  peripherals  that  can  range  from  simple  intelligent  controllers  up 
through  controllers  that  function  as  a  data  base  processor. 

•  It  would  appear  that  IBM.  has  elected  to  go  with  the  intelligent  controller 
approach.  The  3380,  which  was  announced  with  the  4300  series,  has  capa- 
bilities that  have  not  yet  been  applied  to  software  support.  The  channels 
announced  with  the  3081  will  provide  sufficient  capacity  to  handle  the 
anticipated  data  flow  from  the  nodes. 

•  This  approach  is  clearly  at  the  low  end  of  the  DBM  spectrum,  but  from  IBM's 
point  of  view,  it  has  the  advantage  of  permitting  controlled  improvement  in 
DBM  performance. 

Originally,  some  access  method  functions  could  be  distributed;  e.g.,  arm 
positioning,  record  content  searches,  and  error  detection  and  correc- 
tion. 

This  migration  of  function  from  the  mainframe  to  the  controller  could 
result  in  significant  performance  improvement  for  the  DBMS,  and  it 
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also  could  make  life  somewhat  miserable  for  the  plug  compatible 
mainframe  manufacturers. 

•         This  evolutionary  approach  on  IBM's  part  could  be  disrupted  by  rapid  develop- 
ment in  other  areas. 

The  possibility  of  a  "super  smart"  intelligent  controller  incorporating 
current  technology  and  new  architecture  is  represented  by  the 
University  of  Toronto's  Relational  Associative  Processor  (RAP).  This 
DBM  caused  considerable  interest  while  still  in  the  prototype  stage. 
RAP  improves  performance  for  relational  data  base  functions  through 
improved  rotational  storage  (intelligent  head-per-track  storage)  and 
electronic  memories  implemented  in  Charge  Coupled  Devices  (CCDs) 
and/or  Bubble  Memory.  Thus  true  parallel  processing  eliminates  indices 
and  all  the  problems  associated  with  retrieval  of  information  and 
maintenance  of  the  data  base. 

The  application  of  specialized  DBMS  on  minicomputers  in  specific 
environments  can  also  lead  to  tremendous  improvements  in  system 
performance.  The  burden  of  conventional  operating  systems'  overhead 
in  the  nodal  configurations  depicted  in  Exhibit  II- 1  cannot  be  over- 
emphasized. The  announcement  of  MVS  support  for  the  4341  may  make 
it  a  "bridge  machine,"  but  it  cannot  possibly  compete  against  a 
dedicated  minicomputer  for  DBMS  applications. 

DBMs  deployed  in  a  network  operate  as  loosely  coupled  processors  and 
function  as  co-equals,  rather  than  as  slaves  to  a  host  (as  in  SNA).  Many 
analysts  thought  the  IBM  8100  could  function  in  such  a  manner  using  the 
DPPX  operating  system.  However,  problems  of  programming  and 
processor  speed,  and  mass  storage  limitations  effectively  ruled  it  out. 

Network  Node  Data  Management  Machines  (NNDMM),  as 
presented  in  technical  publications,  cause  several  commmuni- 
cations  problems  (such  as  propagation  delay)  that  should  be 
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alleviated  by  satellite  communications  and  improved  query 
languages  early  in  the  1980s. 

The  backend  DB  processor  to  a  large  host  has  been  discussed  for  many 
years.  Fundamentally,  the  purpose  of  the  backend  DBM  is  to  reduce 
mainframe  load,  improve  DBMS  performance,  and  improve  security  on 
the  network.  Once  again,  the  economies  are  achieved  by  specialization 
(simplification)  of  function,  and  a  "close"  coupling  to  the  host. 

At  this  time  it  is  possible  to  speculate  on  the  role  of  the  "dyadic" 
processors  within  the  3081.  It  is  certainly  plausible  that  one 
could  be  used  as  a  DB  engine  in  certain  configurations.  This 
would  represent  a  "tight"  coupling  of  general  purpose  computer 
and  DBM.  However,  the  concept  of  the  backend  "closely" 
coupled  system  has  been  around  for  some  time  and  is  also  a 
revenue  producer.  The  Adabas  backend  costs  approximately 
$400,000. 

It  is  probable  that,  if  IBM  feels  challenged,  it  would  prefer  to 
improve  peformance  at  additional  cost  with  the  closely  coupled 
backend. 

All  the  DBM  technology  mentioned  above  is  certainly  within  the  scope  of  IBM's 
capability.  IBM  research  was  exploring  associative  memories  over  15  years 
ago.  It  is  probable  that  IBM  can  move  in  any  direction  based  on  any  specific 
competitive  threat.  However,  a  casual  threat  does  little  to  prompt  IBM  - 
witness  the  3705,  which  has  been  a  candidate  for  replacement  from  the  day  of 
announcement. 

The  probable  impact  of  DBMs  is  in  the  standalone  and  network  configurations, 
where  tremendous  performance  differences  can  be  isolated.  The  threat  of  a 
backend  computer  can  probably  be  contained  with  the  application  of  IBM 
intelligent  controllers. 
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C.       THE  THREAT  FROM  WITHIN 


•  The  current  internal  conflict  between  DPD  and  GBG  (General  Business  Group) 
within  IBM  continues  despite  IBM's  policy  statement.  A  competitive  environ- 
ment is  still  encouraged,  and  GSD  came  out  with  the  first  IBM  relational 
"DBM"  in  the  System/38. 

•  It  is  INPUT'S  opinion  that  DPD  is  not  especially  concerned  with  compatibility, 
except  within  its  domain.  Therefore,  compatability  between  4300  series  nodal 
systems  with  host  303X  series  and  308X  series  will  be  stressed,  rather  than  use 
of  the  System/38. 

•  The  threat  to  DPD  is  that  System/38  will  become  a  major  success  (despite  late 
shipment).  If  this  occurs,  early  announcement  of  a  relational  DBMS  for  DPD 
systems  could  be  forced.  However,  corporate  IBM  may  decide  to  remain  on 
schedule,  depending  on  the  specific  financial  implications. 

D.       THE  THREAT  FROM  WITHOUT 


•  Much  has  been  written  about  the  Bell  Systems'  Advanced  Communication 
Service  (ACS),  both  its  potential  and  its  problems.  With  the  FCC  ruling  in  the 
Second  Computer  Inquiry,  it  is  probable  that  many  new  and  advanced  services 
will  be  forthcoming  from  common  carriers,  value-added  networks  (VANs)  and 
computer  services  companies.  None  of  these  is  more  significant  than  ACS, 
because  of  Bell  System  resources  in  technology,  capital,  geographic  coverage, 
and  maintenance  facilities. 

The  many  services  promised  by  ACS  include  some  that  border  on  DBMS. 
For  example: 
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Does  store  and  forward  become  a  data  base  system  by  including 
computational  capabilities  and  selective  retrieval  capabilities? 

When  does  on-site  communications  hardware  become  competi- 
tive with  both  general-purpose  computer  systems  and  DBMs? 

These  questions  are  open  to  speculation  at  the  present  time.  The 
current  mood  in  the  FCC  is  toward  deregulation,  and  the  Reagan 
administration  will  certainly  not  attempt  to  reverse  this  trend. 

Only  recently,  the  restriction  of  requiring  a  separate  organizational 
entity  for  marketing  "enhanced  services"  was  removed  from  GTE. 
Since  GTE  has  already  acquired  Telenet,  its  capabilities  for  expanding 
into  the  data  base  area  are  excellent. 

Tymshare,  which  has  already  formed  TYMNET  as  a  VAN,  is  very 
interested  in  providing  data  base  services  using  three  data  base 
systems:  EXPRESS,  FOCUS,  and  MAGNUM.  With  the  FCC  ruling, 
direct  marketing  of  combined  computer/communications  services  will 
unquestionably  begin. 

Those  computer  services  companies  that  have  not  spun  off  separate 
organizations  for  communications  services  will  now  feel  free  to  provide 
network  services  without  fear  of  regulation. 

•  In  addition  to  the  merging  of  computer  services  with  communications  services 
provided  by  common  carriers  and  VANs,  on-line  data  base  services  could  have 
a  significant  impact  on  IBM's  strategy. 

INPUT  has  forecast  that  on-line  data  base  services  will  grow  from  $1.2 
billion  in  1979  to  $4.3  billion  in  1985. 
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Significantly,  most  of  these  proprietary  data  bases  do  not  use  IMS-type 
DBMS,  but  rely  on  systems  such  as  STAIRS  (Structured  Access  Informa- 
tion Retrieval  System). 

The  hardware  and  software  to  support  a  $4.3  billion  business  cannot  be 
ignored  by  IBM:  it  must  provide  easy-to-use  and  efficient  data  base 
systems.  The  users  of  proprietary  DBMS  are  normally  not  systems 
people,  and  transaction  billing  precludes  heavily  burdened  systems  such 
as  IMS  from  being  competitive  in  this  marketplace. 

As  office  automation  evolves  toward  the  "office  of  the  future,"  the  need  to 
integrate  image  processing  with  DBMS  becomes  critical.  Current  IBM  DBMS 
systems  were  not  designed  to  support  such  integration. 

Once  again  it  is  a  question  of  merging  technologies  and  information 
management  versus  data  management.  Numerous  vendors  are  consid- 
ering "electronic  file  cabinets"  for  the  office  so  that  documents  can  be 
retrieved.  The  extension  of  current  DBMS  to  include  images  may  occur 
quite  rapidly. 

The  rapid  development  of  word  and  text  processing  systems  may  also  prompt 
change  in  current  data  management  concepts.  When  it  becomes  cheaper  to 
store  images  of  documents  (reports,  correspondence,  graphics,  etc.)  on  elec- 
tronic media  rather  than  on  paper,  the  concepts  of  retrieval  and  manipulation 
of  individual  data  elements  will  change  drastically. 

Multifunction  office  equipment  will  be  able  to  produce  and  store 
meaningful  information  in  image  form  more  economically  than  a  large, 
centralized  host  computer  with  its  tremendous  systems  software  over- 
head. 
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Numerous  current  vendors  are  aware  of  these  opportunities,  and 
numerous  others  are  becoming  sensitive  to  the  potential  market. 
Getting  technology  into  the  office  environment  requires  changing 
current  thinking  about  information  retrieval. 

In  summary,  the  expense  of  the  overhead  associated  with  current  IBM  DBMSs 
will  be  exposed  once  billing  for  network  services  becomes  transaction- 
oriented.  IBM  recently  released  the  following  numbers  when  refuting  the 
statement  that  it  was  impossible  to  bridge  IMS  to  a  relational  system: 

The  airline  control  program  (ACP),  which  was  hand-tailored  for  rapid 
response,  can  achieve  rates  of  up  to  180  transactions  per  second. 

The  rate  with  hierarchical  models  is  between  20  and  50  transactions  per 
second. 

The  rate  with  a  relational  model  (System  R)  is  between  3  and  20 
transactions  per  second. 

Presumably,  the  hardware  configurations  were  comparable,  it  was  specifically 
stated  that  all  were  tested  on  5M-byte  hardware.  The  following  conclusions 
can  be  reached: 

The  burden  of  standard  IBM  operating  systems  and  IMS  causes  a  system 
to  operate  at  approximately  I  1%  to  28%  of  a  hand-tailored  system. 

If  System  R  is  used,  the  transaction  rate  is  between  1.6%  and  11%  of  a 
custom  system. 

In  other  words,  if  current  IBM  DBMS  support  (IMS)  is  used,  it  requires  3.5  to  9 
times  as  much  processing  power  as  a  dedicated  system.  For  a  "user-friendly" 
system  such  as  System  R,  it  will  require  9  to  62.5  times  as  much  processing 
power. 
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The  problem  is  probably  worse  than  the  above  ratios  indicate  because,  if 
multiple  systems  are  required  to  access  the  same  data  base,  contention  among 
systems  would  impact  performance  (as  evidenced  by  MP  systems  with  only  two 
processors). 

It  would  certainly  appear  that  IBM  must  start  thinking  about  the  problems 
associated  with  large  centralized  data  bases.  There  are  only  two  alternatives: 

Replace  not  only  the  DBMS,  but  the  operating  systems  as  well. 

Off-load  the  large  mainframes  by  employing  both  backend  and  dis- 
tributed DBMs. 

INPUT  does  not  feel  that  IBM  is  going  to  replace  MVS  or  IMS.  Therefore,  it 
must  eventually  distribute  processing  power  and  data  bases  both  geograph- 
ically and  architecturally. 

IBM  sincerely  wants  to  make  its  data  base  strategy  work.  For  example,  IBM's 
largest  internal  system  is  the  Advanced  Administrative  System  (AAS).  This 
system  was  implemented  in  the  1960s  on  a  custom  basis  using  BDAM.  The 
system  needs  to  be  replaced,  and  there  is  some  sentiment  for  using  IMS,  since 
that  is  what  IBM  is  urging  customers  to  do.  The  problems  are  comparable  to 
those  of  converting  the  ACP  to  a  generalized  DBMS,  and  the  IMS-oriented 
AAS  probably  never  would  be  a  viable  replacement. 
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PREDICTING   WHAT   IBM   WILL  DO 


IV 


PREDICTING  WHAT  IBM  WILL  DO 


A.       EVOLUTION  OR  REVOLUTION 

•  INPUT  has  already  determined  that  IBM  would  prefer  to  be  conservative  in  its 
DBMS  approach.  Considering  the  performance  problems  cited  above,  this  is 
understandable,  and  the  approach  may  be  best  for  customers. 

•  However,  customers  requiring  very  large  data  bases  with  high  transaction 
rates  may  be  in  for  some  unpleasant  surprises,  even  with  the  additional 
processing  power  associated  with  the  3081. 

•  IBM  has  always  been  responsive  to  large  customers.  As  these  problems  start 
to  surface,  there  will  be  internal  pressure  to  expedite  schedules  on  both 
delivery  and  announcements. 

•  Therefore,  IBM  may  be  forced  to  change  its  plan,  just  as  it  did  with  the 
announcement  of  the  3033.  However,  the  architecture  of  the  3081  and  its 
channels,  along  with  the  3880  controller,  gives  IBM  flexibility  that  was 
unavailable  in  previous  systems.  Announcements  of  both  hardware  and 
software  will  be  phased  in  under  rigid  control,  which  will  continue  to  confound 
competitors,  customers,  and  consultants. 
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THE  ARCHITECTURE  OF  FUTURE  DB/DC  NETWORKS 


•  Exhibit  ll-l   depicted  a  potential  node  using  current  IBM  equipment.     It  is 
basically  a  DPD-oriented  node. 

The  8100  could  theoretically  be  replaced  with  products  from  either 
competitors  or  GSD  and/or  OPD. 

The  4300  could  be  replaced  with  a  System  38  in  certain  environments, 
or  it  could  grow  into  a  30XX  system;  but  functionally  the  node  would 
remain  the  same. 

•  When  DBMs  become  available,  the  overall  network  will  have  substantially 
more  architectural  flexibility,  as  shown  in  Exhibit  IV- 1. 

The  potential  of  this  type  of  network  will  be  determined  by  software, 
not  hardware.  An  8100  is  included  in  this  network,  but  it  will  not  play  a 
significant  role  in  a  distributed  DBMS  for  the  following  reasons: 

The  8100  shown  will  be  operating  in  DPCX  mode  (essentially  as  a 
cluster  controller)  because  this  will  be  encouraged  by  IBM.  If 
users  want  to  design  and  implement  their  own  networks  using 
DPPX,  they  will  not  receive  much  assistance  from  IBM.  This 
"roll  your  own"  attitude  is  not  designed  to  promote  deviations 
from  SNA. 

The  disk  storage  capacity  of  the  8100  precludes  its  use  as  the 
primary  system  in  most  large-company  environments.  As  office 
automation  develops,  this  limitation  will  be  even  more  pro- 
nounced. 

The  systems  software  support  is  not  in  the  "mainstream"  of  IBM's 
plan  for  growth  at  the  distributed  nodes. 
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EXHIBIT  IV-1 
POTENTIAL  NETWORK  ARCHITECTURE 
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The  8100  is  not  designed  to  be  a  DBM,  and  it  will  not  be 
supported  for  distributed  data  base  except  in  what  amounts  to 
3790. 

INPUT  believes  that  the  8100  will  function  under  a  larger 
system,  whether  that  system  is  a  remote  host  or  a  local 
distributed  processor,  as  shown  in  Exhibit  1V-I. 

It  is  clear  that  IBM  must  support  computer-to-computer  communication 
between  hosts  and  distributed  processors.  However,  the  question  is 
whether  IBM  will  support  both  general-purpose  systems  (4300  series  and 
308X  series)  and  DBMs  for  distributed  data  bases. 

INPUT  believes  that  IBM  will  eventually  support  both,  and  that  the 
primary  DBMS  at  these  nodes  will  be  relational. 

The  connection  of  a  DBM  directly  to  the  network  (as  opposed  to  using  it 
as  a  backend)  will  support  all  data  models  (hierarchical,  network,  and 
relational)  depending  upon  the  particular  requirements  of  the  node. 

The  DBMs  will  be  dedicated  to  particular  data  models,  and  their 
performance  will  be  significantly  better  than  the  general-purpose 
systems  (when  running  a  DBMS). 

The  host  can  also  communicate  with  a  complex  distributed  node,  which 
includes  its  own  communications  processor  and  multiple  backend  DBMs. 
In  fact,  it  is  possible  that  some  distributed  nodes  could  outgrow  their 
host  systems  in  terms  of  processing  power. 

In  this  case,  a  large  node  could  literally  serve  as  backup  for  the 
host  for  network  management  purposes. 
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Indeed,  a  network  could  be  designed  to  provide  for  a  backup 
system  that  could  take  over  all  the  functions  of  the  host  - 
including  a  copy  of  all  host  data  bases. 

•  The  "network  manager"  shown  in  Exhibit  IV- 1  should  not  be  confused  with  the 
long-suffering  concept  of  a  network  control  program  (NCP),  which  has  been 
established  under  SNA.  A  true  network  management  facility  would  be  devoted 
to  monitoring  and  controlling  the  network. 

This  would  include  not  only  traditional  communications  services  such  as 
logging  performance,  error  correction,  and  rerouting,  but  also  store- 
and-forward  message  services  and  directories  for  the  network. 
Directories  are  used  to  identify  people,  organizations,  physical  loca- 
tions, and  terminals. 

In  many  ways,  the  network  manager  would  perform  many  of  the 
functions  promised  by  ACS.  The  decision  to  provide  for  such  functions 
in  a  private  network,  or  to  purchase  the  service  from  a  common  carrier, 
will  depend  upon  implementation  and  the  individual  company's  reguire- 
ments. 

Host  systems  will  share  responsibility  for  data  dictionaries  with  the 
distributed  systems,  but  once  again  the  network  management  function 
includes  the  ability  to  seek  out  specific  items  of  data  and  information 
within  the  network. 

It  is  probable  that  IBM  will  continue  to  maintain  both  directories  and 
dictionaries  on  large  general-purpose  systems,  even  after  they  replace 
the  3705.  However,  there  is  no  reason  that  the  communications 
processors  cannot  perform  those  functions. 

•  It  is  also  probable  that  IBM  will  use  intelligent  controllers  for  initial  steps  into 
backend  data  base  machines.  Sitting  behind  the  host  -  but  also  interfacing  as  a 
distributed  node  -  the  network  depicted   in  Exhibit   IV-I    illustrates  both 
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geographic  and  architectural  distributed  data  processing  and  distributed  data 
base. 

•  It  is  INPUT'S  opinion  that  IBM  will  support  a  version  of  the  "coexistence 
model"  mentioned  previously.  This  opinion  does  not  imply  that  IBM  necessarily 
wants  to  support  this  model;  it  may  simply  be  a  question  of  being  forced  to 
support  all  major  data  models.  It  will  be  accomplished  through  integration  of 
additional  models  with  existing  systems. 

•  INPUT  believes  that  the  bridge  problem  can  be  solved,  and  that  IBM  will  do  an 
acceptable  job  of  solving  it.  However,  the  performance  problems  will  not 
necessarily  be  alleviated  by  distributed  processing  on  backend  DBMs.  The 
ratios  presented  earlier  defy  hardware  solutions  alone,  and  it  is  INPUT'S  belief 
that  IBM  will  not  make  major  structural  changes  to  its  basic  software  support 
plan. 


C.       PROJECTED  ANNOUNCEMENT  DATES  FOR  NEW  TECHNOLOGY 


•         Ideally,  IBM  would  prefer  to  continue  its  conservative  DBMS  approach,  as 
shown  in  Exhibit  IV-2.  This  approach  has  the  following  time  schedule: 

In  1981,  IBM.  will  announce  a  relational  system  for  large  host  systems. 
In  addition,  certain  data  base  functions  will  be  distributed  to  the  3880. 
Last  but  not  least,  it  will  anounce  a  new  communications  front  end. 
(Predicting  the  replacement  of  the  3705  is  perhaps  an  example  of  what 
should  be  done  rather  than  what  IBM  will  do.  However,  INPUT  has 
predicted  this  for  so  long  that  it  does  not  wish  to  miss  the  actual 
announcement.) 
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In  1982,  IBM  will  announce  a  relational  DBMS  for  the  nodes.  This 
system  will  be  available  on  4300  series  and  308X  series,  but  not  on 
303X.  Additional  data  base  support  for  the  3880  and  308X  channels  will 
also  be  announced. 

In  1983,  interconnection  of  major  nodes  and  support  of  distributed  data 
base  will  be  announced.  The  303X  will  be  included  in  this  support  (along 
with  the  4300  and  308X),  but  only  for  access  to  IMS  data  bases. 

In  1984,  a  backend  DBM  will  be  announced  along  with  one  or  more  new 
nonprocedural  language(s)  for  office  automation.  In  addition,  the 
interconnection  of  DPD/GSD/OPD  products  will  be  supported. 

In  1985,  DBMSs  will  be  extended  to  include  GSD  and  OPD  products. 
This  will  be  done  with  DBMs  that  support  other  data  base  and 
information  management  systems  (including  the  network  model)  and 
will  have  image  retrieval  capability.  At  this  point  DBMSs  become  true 
information  resource  managers. 

In  1986,  the  network  and  DBMSs  will  be  extended  to  include  competi- 
tive hardware  and  DBMS  systems.  This  is  necessary  because  networks 
will  become  interconnected. 

It  is  INPUT'S  belief  that  IBM  has  a  good  chance  of  maintaining  this  schedule. 
However,  a  great  deal  depends  upon  how  it  supports  current  products  such  as 
the  3880.  It  is  possible  that  the  3880  could  be  supported  at  a  level  where  it 
could  qualify  as  a  true  DBM.  Thus  a  backend  DBM  could  appear  two  years 
early  (1982). 

In  addition,  it  is  possible  that  the  network  data  model  could  be  supported  two 
years  early  (1983). 

Under  any  circumstances,  the  general  schedule  will  be  to  concentrate  on  large 
customers  during  the  early  1980s  using  an  SNA  type  of  approach  to  control  the 
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amount  of  processing  that  can  be  distributed.  The  mid-1980s  will  see  true 
distributed  processing  and  data  bases.  At  this  point,  IBM  will  be  positioned  to 
integrate  office  automation  with  data  processing  systems. 
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